DBT Support

Quest Data Modeler integrates with DBT (Data Build Tool) to generate DBT-compatible YAML files directly from your models. Instead of hand-authoring model and source definitions, you generate them from a model that is saved in Quest erwin Mart Portal and opened in Quest Data Modeler. This enables faster setup, consistent metadata, and fewer errors when you build data tables and transformations in DBT.

To control the output, on the Export Configuration: DBT page, you can select the file format, the column ordering, and exactly which user-defined properties (UDPs) are written into the YAML metadata.

Note: The DBT option is available only for models that are saved on the mart. Save your model to the mart before you begin.

Generating YAML Files

  1. On the Overview page, select Open Mart Model.

    The Catalog Manager page opens.

    Select a mart model from Mart Portal Catalog Manager

  2. Select the model, and then select Open.

    You can also select Model kebab menu for more actions on a model on the model node, and then select Open in Modeler.

    The model opens in Diagram View. For example, the Lead-to-Cash Model opens.

    Mart model, Lead-to-Cash, opened in the modeler

    This model has the following UDPs set up:

    Level Model Object UDP name Logical/Physical
    Model Model business_process Logical
    retention_period Logical
    source_system Physical
    target_platform Physical
    Entity Lead sla_tier Logical
    pii_present Logical and Physical
    load_frequency Physical
    Attribute LeadName data_classification Logical
    pii_flag Logical
    business_key Physical
    currency_code Physical
  3. On the tool bar, select Diagram editor's toolbar's Mart button, and then select DBT.

    The Export Configuration: DBT page opens.

    DBT export configuration screen

  4. Click the File Format drop-down list and select one of the following options:

    • Model: Specifies that the generated YAML file defines the model as a transformational file for DBT, including column metadata, tests, and inter-model relationships.

    • Source: Specifies that the generated YAML file defines the model as raw tables, including location, columns, tests, and relationships.

    Note: Model-level UDPs are written to the meta.source_metadata section, which is generated only in Source file format. When you generate in Model file format, the output includes entity-level (meta.table_metadata) and attribute-level (meta.column_metadata) UDPs only. To include model-level UDPs in the output, select Source from the File Format list.

  5. Click the Columns Ordering drop-down list and select the order in which columns appear in the output:

    • Attributes_Order_Ref: Specifies that the column ordering aligns with the logical order of attributes defined in the data model.

    • Columns_Order_Ref: Specifies that the column ordering aligns with the physical order in which columns are defined in the table.

    • Physical_Columns_Order_Ref: Specifies that the column ordering aligns with the physical layout of columns as stored in the database.

  6. Click Generate.

    Your model's DBT compatible YAML code is generated. You can save it using the Save button button.

    DBT-compliant YAML script generated for the Lead-to-Cash model

To filter the UDPs that are generated in the output, follow these steps:

  1. Create a UDP selection schema (XML file) using any text or XML editor. Save the file to a known location.

    This XML file is where you define the include and exclude filters. For more information and examples on filtering, refer to the Selecting UDPs to export section.

    For example, for the Lead-to-Cash model, if you want to filter and include a mix of specific UDPs in the YAML script, the UDP selection schema would be:

    Copy
    <UdpSelection>
      <Model>
        <Include>logical</Include>
        <Exclude>logical:retention_period</Exclude>
      </Model>
      <Entity>
        <Include>physical</Include>
      </Entity>
      <Attribute>
        <Include>physical:business_key</Include>
      </Attribute>
    </UdpSelection>

    This schema includes all logical model UDPs except retention_period (leaving only business_process), all physical entity UDPs (load_frequency and pii_present), and only the physical attribute UDP, business_key. Everything else is left out.

  2. Click the File Format drop-down list and select Source so that model-level UDPs are included in the YAML script.

  3. Select Include an XML Schema.

    The file attachment field is enabled.

    DBT generation screen with UDP selection field

  4. Attach the UDP selection schema file that you created in Step 1.

  5. Click Generate.

    Based on the UDP selection schema, the generated YAML script includes:

    • Logical model-level UDP, business_process

    • All physical entity UDPs, load_frequency and pii_present

    • Only the physical attribute UDP, business_key.

    DBT-compatible YAML script with filtered UDPs

You can use the following options on the generated YAML script.

  • Print (Print icon): Use this option to print the generated script.

  • Search (Find icon): Use this option to search for a word or characters in the schema.

  • Copy (Copy icon): Use this option to copy the script.

  • Replace (Replace icon): Use this option to find and replace characters in the script.

  • Text Display Options (Text Display Options icon): Use this option to configure the preview text editor's look and feel, such as window, font, and syntax color settings.

Selecting UDPs to Export

By default, the YAML generator writes every UDP it finds in the model at the model, entity, and attribute levels to the YAML metadata. To narrow this down to only the UDPs that matter to you, you can define inclusion and exclusion filters in a UDP selection schema XML file.

Key benefits:

  • Cleaner YAML output: Only business-relevant UDPs are emitted.

  • Consumer control: Each consumer can define their own metadata contract without changing the utility.

  • Lower downstream maintenance: Fewer unexpected metadata keys are included in DBT projects.

  • Safe adoption: This is an optional feature with no impact to existing integrations unless schema is passed.

  • Supports real modeling patterns: Works for logical-only, physical-only, or mixed UDP usage.

You can create the XML file in any text or XML editor, then attach it in the Schema section before you generate.

Scope the Selection by Object Level

Filtering is available for three object levels, each of which maps to a metadata section in the YAML:

Object level

YAML metadata section

Model

meta.source_metadata

Entity

meta.table_metadata

Attribute

meta.column_metadata

Note: Only model, entity, and attribute-level UDPs are supported. UDPs defined on other objects (for example, annotations) are not included in DBT output.

For each object level, you can:

  • Include or exclude UDPs by scope: Choose Logical or Physical side to act on all UDPs of that scope at once.

  • Include or exclude specific UDPs by name: Pick individual properties when you need fine-grained control. You can refer to a UDP by its plain name (for example, business_process) or by a scope-qualified name (for example, logical:business_process) when you want to target only one scope.

Note: When you specify a scope-qualified UDP name, the corresponding UDP is included or excluded if it exists in the model. If the specified UDP is not found, the filtering process continues and YAML generation is not affected.

If you leave an object level unfiltered, all of its UDPs are included. This means logical-only, physical-only, and mixed models are all supported without extra setup.

How Filtering Works

  • All by default: If you do not attach a schema, all UDPs are included in the generated YAML.

  • Section scope: Rules apply only within their own section (Model, Entity, or Attribute).

  • Omitted section: If you leave out a section, all UDPs for that section are included in the generated YAML.

  • Exclude overrides Include: If the same UDP is both included and excluded, it is excluded from the output.

  • Logical and physical are independent: UDPs on the logical side and the physical side are treated separately. You can include one side and leave out the other.

  • No duplicates: If several rules match the same UDP, it is included once. If a logical and a physical UDP share the same name and both are selected, both values are kept using scope-specific keys.

Schema Structure

The schema is an <UdpSelection> element with a section for each object level. Within a section, use <Include> and <Exclude> rules. Use the following structure:

Copy
<UdpSelection>
  <Model>
    <Include>...</Include>
    <Exclude>...</Exclude>
  </Model>
  <Entity>
    <Include>...</Include>
    <Exclude>...</Exclude>
  </Entity>
  <Attribute>
    <Include>...</Include>
    <Exclude>...</Exclude>
  </Attribute>
</UdpSelection>

Schema Examples

Include all logical model UDPs:

Copy
<UdpSelection>
  <Model>
    <Include>logical</Include>
  </Model>
</UdpSelection>

The generated YAML is as follows:

 

Include only physical entity UDPs:

Copy
<UdpSelection>
  <Entity>
    <Include>physical</Include>
  </Entity>
</UdpSelection>

 

Mix broad and specific rules across levels:

Copy
<UdpSelection>
  <Model>
    <Include>logical</Include>
    <Exclude>logical:retention_period</Exclude>
  </Model>
  <Entity>
    <Include>physical</Include>
  </Entity>
  <Attribute>
    <Include>physical:business_key</Include>
  </Attribute>
</UdpSelection>